This invention relates to the diagnostics of circuit card assemblies (CCAs) or other electronic circuits for troubleshooting in a manufacturing or repair facility and the validation of prototypes and new designs. A typical test sequence for conventional troubleshooting and repair may involve two main functions: (1) to test a defective CCA using an automated testing device; and (2) to manually troubleshoot the CCA by providing the necessary input power and stimulus functions to diagnose the automated test failure to the individual failed component.
The first function, generation of the automated test, is typically performed by an engineer who may follow the following representative development sequence:                a. Review the CCA test requirements.        b. Review the CCA schematic.        c. Review the CCA physical requirements.        d. Review the host test system capability.        e. Design each electrical test of the CCA requirements with respect to the host test system.        f. Design a physical interface which allows connection of the CCA to the host test system.        g. Manufacture an interface between the CCA-to-test-system.        h. Write CCA test code.        i. Debug CCA test code.        j. Generate the respective CCA test documentation.        
The test sequence for new prototypes or CCAs under development may involve many iterations of design and redesign, simulation, and testing and evaluation. Testing of new designs typically may be performed in a manual or limited automated test environment, because the test design may undergo as many redesigns as the target CCA.
The conventional automated test generation sequence is typically time consuming and expensive. The expense of conventional automated test generation, while inefficient, may be recovered if a sufficient number of CCAs are tested, such as in a high volume, new production process. The repair process differs in that the volume of CCAs is typically significantly less, making the cost of the automated test generation impractical, but in many cases still necessary to meet the customer's needs.
After automated testing, the second function, manual troubleshooting of the CCA, is typically performed by a technician who may follow the following sequence steps:                a. Review the CCA test failure or design specifications with respect to the test requirements.        b. Review the CCA schematic.        c. Review the CCA physical requirements.        d. Devise a method to manually apply power and stimulus to the CCA in an effort to duplicate the automated test or performance failures.        e. Diagnose the fault to the failed component.        f. Replace the failed component.        g. Manually test the CCA to verify that the repair or rework was successful.        h. Test the CCA using the automated test to ensure full CCA functional compliance.        
Manual test and diagnostics of each defective CCA is typically labor intensive because it requires individual attention to connect the CCA to the manual test device and to manually perform associated instrumentation setups for test diagnostics. Once the diagnostics are complete, intelligence gleaned during the process is lost by dismantling the test setup through physical disconnection and changing of instrumentation settings. While instrumentation costs associated with manual testing are typically lower than those associated with automated testing, the need to repeat the entire manual testing process for subsequent identical CCAs tested at other times renders the process very inefficient.
In past years, technicians have occasionally resorted to using physical templates that can be overlaid onto a manual cross-point matrix, with apertures formed to indicate where test equipment leads should be connected to the CCA. While creating a record of instrument to CCA connection, this method is cumbersome, potentially inaccurate, and is subject to destruction during the period of storage between tests.
Various software programs have been developed to assist the automated testing engineer with discreet portions of the test development process. The LABVIEW™ program from National Instruments Corporation, Austin Tex. is a test program development tool that provides a graphical environment for creating test, measurement and control routines, using graphical drivers to represent instrument controls and switching. A related type of program available from Keithley Instruments, Inc. as the TESTPOINT™ development package provides a graphical programming aid for application code creation by dragging and dropping objects representing graphs, displays, and other parts of a test on a display panel and listing desired test actions. While providing a way to create test applications without drafting new code, this program does not represent the CCA schematic in the graphical environment, does not interface with the CCA or actual instruments, and does not effectuate an actual CCA test.
Another tool that may be used by engineers is the PSPICE® program from Cadence Design Systems, Inc., which provides a predictive simulated graphical analytical environment as an aid for designing circuits. This program allows an engineer to draw and graphically illustrate a circuit on a display, and the program will then create a suggested circuit board layout and predict the outcome of simulate tests run on the circuit. However, the program works only with Spice type language drawings, does not provide for graphical or actual connection of instruments to the CCA, does include actual instrumentation, and does not provide for testing of actual CCAs.